Verichains
Guardians of Web3
We offer unparalleled protection for your organization by combining cutting-edge security research with deep reverse engineering expertise. As a reliable security partner, we ensure robust security for the development and deployment of your mission-critical software. Renowed for having investigated and mitigated some of the biggest hacks in Web3.
Request a consultation
Empowering Enterprises
to Mitigate Risk
We help organizations seamlessly integrate and experiment with cutting-edge technologies in a secure and compliant manner. Enterprises can leverage our unique mix of cross domain expertise and extensive experience in cryptography, blockchain, application security, and low-level security engineering. Our commitment to providing world-class service is demonstrated by our certifications and accreditations, including ISO 9001, ISO 27001, PCI-DSS, and proud membership in CREST.
Request a consultation
Trusted by
Market Leaders
Home to elite white-hat hackers and security researchers, we are dedicated to advancing security in the rapidly evolving blockchain landscape. Our team conducts pioneering research in emerging technologies, with notable projects like TSSHOCK, a comprehensive security survey of Multi-Party Computation (MPC) that has safeguarded billions of dollars in digital assets, and Revela, an advanced decompiler for the Move language. These projects demonstrate our commitment to critical vulnerability research, ensuring that our clients and partners benefit from the highest levels of protection and assurance.
Request a consultation
our services
Before hackers can exploit hidden on-chain or off-chain vulnerabilities in your software, organizations can leverage our tailored security assesssments to proactively hunt, discover, and resolve vulnerabilities in any blockchain implementation, consensus protocol, smart contracts, or decentralized application.
When automated testing falls short, our tailored full-scale penetration testing services simulate real-world cyber attacks to assess your defenses, response capabilities, and overall resilience. This prepares your organization to effectively respond to and recover from actual threats, making it a critical exercise for any enterprise serious about security.
Our GRC consultancy helps your organization navigate and meet regulatory and compliance requirements cost-effectively. We provide advice and implementation services for SOC 2, ISO 27000 series, GDPR, and PCI DSS compliance with end-to-end support. We apply industry best practices in risk management, with tailored security frameworks that not only meet standards but also enable robust protection for your business.
Before hackers can exploit hidden on-chain or off-chain vulnerabilities in your software, organizations can leverage our tailored security assesssments to proactively hunt, discover, and resolve vulnerabilities in any blockchain implementation, consensus protocol, smart contracts, or decentralized application.
When automated testing falls short, our tailored full-scale penetration testing services simulate real-world cyber attacks to assess your defenses, response capabilities, and overall resilience. This prepares your organization to effectively respond to and recover from actual threats, making it a critical exercise for any enterprise serious about security.
Our GRC consultancy helps your organization navigate and meet regulatory and compliance requirements cost-effectively. We provide advice and implementation services for SOC 2, ISO 27000 series, GDPR, and PCI DSS compliance with end-to-end support. We apply industry best practices in risk management, with tailored security frameworks that not only meet standards but also enable robust protection for your business.
Products
Developed by leading security experts at Verichains, BShield is a comprehensive client-side protection that acts as a shield for businesses, protecting them from data breaches, malicious user-side attacks, and ensuring the integrity of information sent to their servers.
Key features
- Mobile shield
- Data protection
- Web shield
- API protection
audit reports
Show
Show
Our Partners
Trusted by market leaders
Latest blogs
View all
Into Curve Invariant - part 2
The second part of this article is about the StableSwap invariant. CryptoSwap The CryptoSwap invariant is a core mathematical formula that defines the "liquidity curve" for Curve's trading pools, specifically designed for highly volatile asset pairs (not tightly pegged like stablecoins). It helps the pool concentrate liquidity around an "internal" price (determined through an internal oracle) and automatically adjusts when the pool becomes imbalanced. Here are the key points: Thanks for reading Verichains! Subscribe for free to receive new posts and support my work. Combining advantages of two invariants: When the pool is balanced (value-equivalent balances), the CryptoSwap invariant behaves similarly to the stableswap invariant, creating a "flat" region (no slippage) that enables near 1:1 exchanges. When the pool becomes imbalanced, the invariant gradually shifts to constant-product invariant behavior (like Uniswap), resulting in increased slippage and protecting the pool against excessive price deviations. Comparison of AMM invariants: constant-product (dashed line), stableswap (blue) and from this work (orange) In Part 1, the StableSwap Invariant is described in the general formula: And the CryptoSwap invariant is encouraged by the StableSwap invariant: however, K is defined slightly differently: A (amplification coefficient): The A parameter, similar to StableSwap invariant (Curve v1), controls how flat the bonding curve is at its center. This determines how concentrated liquidity is around the expected exchange rate (i.e., the "price scale"; see below) Gamma: The gamma parameter controls the separation between the two constant product curves shown in the above figure (dashed lines). When gamma increases, it stretches the "adjusted constant product" curve toward the lower-left corner, moving the curve's asymptotes closer to the axes and broadening the overall curve shape Effects of adjusting the A (left) and gamma (right) parameters. For the left plot, gamma = 0.000145. For the right plot, A = 400,000. The init: With the initial formula, we can rewrite f(D_0) as in a situation which only has 2 coins: D_0^2 = x[0][1]\n","id":"REISSOHDQQ"}" data-component-name="LatexBlockToDOM"> Using Newton's method, the Initial values can be transformed to: With this formula, D_0 can be calculated by looping through A time. In the viper code, A is set to 255. The code calculates the absolute difference between the current and previous values of D_0. It stops iterating when the difference is either very small (diff ≤ 1) or when the difference multiplied by 10^18 is less than D_0. Once one of these conditions is met, the function returns the converged value of D_0. Back to the invariant, let S be the sum of x_i and P is the product of x_i. f(D) with 2 coins (N = 2) becomes: The derivative of f(D) is: This can be transformed to: The above formula can be transformed to simplify. First, divide all terms by K and expand everything inside the parentheses. Now S can be written as - S + 2S: Then, factor out the common terms between the groups containing S and D. Make all denominators inside the parentheses common: Introduce two auxiliary variables, mul1 and mul2, to simplify the variables in the function: The derivative f'(D) now can be reduced to: In the viper code, _g1k0 variable is defined to be: Back into the code, This code calculates -f'(D) instead of f'(D). This makes Newton's step more clear. In addition, f(D) is divided by K: The full Newton's method for D now is: The formula has been separated into two parts for Newton's method: The final D will be calculated as the difference between the two equations above. Thanks for reading Verichains! Subscribe for free to receive new posts and support my work.
Technical Analysis of the Bybit Hot Wallet Exploit
On February 21, 2025, at 14:13:35 UTC, a malicious transaction was executed that upgraded the implementation of the Bybit Hot Wallet Proxy via a call from SafeWallet. This analysis details the sequence of events, on-chain operations, and potential attacker methodology. Compromised Transaction Details Malicious transaction that upgrade implementation of Bybit Hot Wallet called from SafeWallet: Timestamp: Feb-21-2025, 14:13:35 UTC Transaction: 0x46dee (Etherscan) Key Addresses: Bybit Hot Wallet Proxy: 0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4 GnosisSafe (v1.1.1): 0x34cfac646f301356faa8b21e94227e3583fe3f5f Source code of Hot Wallet Bybit Proxy Malicious Implementation Contract: 0x96221423681a6d52e184d440a8efcebb105c7242 Decompiled source code of 0x96221423681a6d52e184d440a8efcebb105c7242 On-Chain Flow of the Exploit Initiation by the Hacker: Hacker Address: 0x0fa09c3a328792253f8dee7116848723b72a6d2e The attacker initiates a call to the Hot Wallet Proxy (0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4). Delegated Calls: The proxy executes a delegatecall to the legitimate GnosisSafe contract (0x34cfac646f301356faa8b21e94227e3583fe3f5f). Next, a further delegatecall is made to the malicious implementation contract using the following JSON payload: { "to": "0x96221423681a6d52e184d440a8efcebb105c7242", // Malicious Implementation Contract "operation": 1, // DelegateCall operation "data": "0xa9059cbb000000000000000000000000bdd077f651ebe7f7b3ce16fe5f2b025be29695160000000000000000000000000000000000000000000000000000000000000000" // Encodes a call to transfer(address,uint256): // transfer(0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516, 0) } State Modification: Within the malicious contract’s transfer function: def transfer(address _to, uint256 _value) payable: require calldata.size - 4 >= 64 require _to = _to stor0 = _to This function updates slot0 of the proxy, effectively replacing the legitimate GnosisSafe implementation with the malicious contract at 0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516. The state change is confirmed by the following screenshot: Proxy implementation’s slot change confirmation Asset Exfiltration: Test Transfer: A preliminary transaction transferred 90 USDT to verify functionality. View on Etherscan Test transfer screenshot Massive ETH Drain: Following the test, a transaction was executed that transferred 401,346.76 ETH from the compromised wallet. View on Etherscan ETH transfer screenshot Final Thoughts The incident is still under investigation. The key details above show how the attacker drained the wallet’s fund and used crafted delegatecall transactions to hide their actions. This information is crucial for understanding the breach. Stay alert and monitor your wallet closely, as even zero-value transactions might signal hidden threats. Further updates will follow as more details emerge. Subscribe now
Four.meme Hack Analysis
Four.meme, a platform for launching meme tokens backed by Binance Academy, was exploited on February 11, 2025, resulting in a total asset loss of approximately $183,000. Analysis Meme.four allows users to create and list new meme tokens for trading. Once a meme coin’s market capitalization exceeds a set threshold, it is migrated to a decentralized exchange (DEX). Thanks for reading Verichains! Subscribe for free to receive new posts and support my work. When migrating a meme token to the DEX, Four.meme attempts to create a new trading pair pool, transferring 200,000,000 meme tokens and approximately 24 WBNB into it before setting the correct sqrtPriceX96 for the pool. However, a vulnerability exists: if the pool already exists, Four.meme will use it without verifying its sqrtPriceX96 value. This allows an attacker to manipulate the price and drain assets from the trading pool. The attack begins when the hacker creates a new meme token, conducts artificial transactions to inflate its market capitalization, and triggers Meme.four to migrate it to the DEX. Figure 1: Migrate meme token to the DeX During migration, Four.meme uses a pre-existing pool with a sqrtPriceX96 value set to ten duodecillion, which is 368 trillion times larger than the correct value (as shown in the red box in Figure 1). The transaction used to create this malicious pool is shown below: Figure 2: Create custom pool with wrong sqrtPriceX96 After the migration, the attacker can withdraw all WBNB from the pool using only a small amount of meme tokens. Figure 3: Withdraw all WBNB with small amount of meme token Conclusion To prevent this attack, Four.meme should implement price verification checks for the liquidity pool before making deposits. Additionally, conducting comprehensive security audits for all products is recommended to identify and mitigate potential vulnerabilities. Thanks for reading Verichains! Subscribe for free to receive new posts and support my work.
ERC-6492 Deployment Vulnerability: Leveraging isValidSignature Bypass via Pre-compiled contract
On January 23, 2025, a vulnerability in the ODOS Protocol’s OdosLimitOrderRouter contract was exploited, leading to the theft of approximately $50,000 on Ethereum and Base. The attack was caused by an arbitrary call vulnerability due to unverified user input combined with a pre-compiled contract to bypass the signature check. Attacker Contract: https://basescan.org/address/0x22a7da241a39f189a8aec269a6f11a238b6086fc Vulnerable Contract: https://basescan.org/address/0xb6333e994fd02a9255e794c177efbdeb1fe779c7 Transaction attack: https://basescan.org/tx/0xd10faa5b33ddb501b1dc6430896c966048271f2510ff9ed681dd6d510c5df9f6 Exploit Analysis The attacker focuses on exploiting arbitrary call, which is used to deploy the ERC6492 contract. They can use the arbitrary call to steal tokens from this contract using ERC20.transfer but must bypass the signature check IERC1271Wallet(_signer).isValidSignature, which initially seems impossible because the _signer code length must be zero - meaning it cannot be executed. However, some special contracts do have zero code length yet can still execute commands: pre-compiled contracts. The attacker used the 0x4 Identity pre-compiled contract, which is designed to copy data between memory portions. After stealing tokens using the arbitrary call, the attacker bypassed the signature check by using the 0x4 contract as _signer. The contract called IERC1271Wallet(0x4).isValidSignature without reverting, successfully completing the exploit. Conclusion When building your own project, does not trust any user input. Any parameter given must be carefully validated by the code. Calls to untrusted contracts can introduce several unexpected risks or errors. External calls can trigger malicious code, either within the target contract or across its ecosystem. Every external call should be treated as a potential security risk and must be processed with extreme caution. Be very cautious when using contract code length, as this can introduce real issues with the contract’s constructor and pre-compiled contracts. Protocols using ERC-6492 should carefully check to mitigate similar risks. Additionally, it is strongly recommended to conduct a security audit, not only for the first release version but also for any new features added in the future. Since the upgrading process can introduce various issues, it should also be thoroughly audited.
zkLend Finance Incident Analysis
On Feb 12, 2025, the zkLend Finance protocol was exploited, resulting in a loss of approximately $9.5 million. zkLend is a decentralized lending protocol that operates on the Starknet blockchain. It allows users to lend and borrow assets, similar to protocols like Aave or Compound. The attack targeted the zkLend Market contract (specifically the wstETH market), which is the main contract that enables users to lend and borrow assets. Key information Attacker address: https://voyager.online/contract/0x04d7191dc8eac499bac710dd368706e3ce76c9945da52535de770d06ce7d3b26 Vulnerable contract (zkLend Market): https://voyager.online/contract/0x04c0a5193d58f74fbace4b74dcf65481e734ed1714121bdc571da345540efa05 Sample attack transaction: https://voyager.online/tx/0x596bb905f74b545ca5a2af39c5724d952e43ef9887af3f6fd603eebfcc9c2a Exploit analysis Looking at the attacker address, we can see that there were multiple transactions that occurred during the time of the attack. To understand the attack, we need to first examine the transaction that calls runwithfirstdep, as it appears to be the most important one. In the runwithfirstdep transaction, we can see multiple consecutive deposit and withdraw calls to the zkLend Market contract. Let's examine the details of one deposit call first. It's clear that the amounts in the deposit and withdraw calls are not the same, indicating this is not a simple deposit and withdraw transaction. Here, we see that the attacker only deposited 4.069 wstETH but withdrew 6.103 wstETH. Therefore, we need to examine the code of the deposit and withdraw functions to understand the attack. Walking through the code of the deposit function, we can see that it takes the amount of input token and mints a corresponding amount of zToken. The same applies to the withdraw function. However, why could the attacker burn more zToken than they should? This leads us to examine the implementation of the burn function in the zToken contract. From the implementation of the burn function, we can see that the actual amount burned is scaledDownAmount. Additionally, by examining the safe_math::sub() function, we can determine that the formula for calculating scaledDownAmount is amount * SCALE / accumulator. So, the easiest way to check this value is by checking these values from the attack transaction. And we have the following values: amount: 6103946859077466029 (withdraw call) accumulator: 4069297906051644020000000000000000000000000000 SCALE: 1000000000000000000000000000 From these values, we can calculate the scaledDownAmount as follows: scaledDownAmount = amount * SCALE / accumulator = 6103946859077466029 * 1000000000000000000000000000 / 4069297906051644020000000000000000000000000000 = 1 So now, it's clear that this value was carefully chosen by the attacker to bypass the check of scaled_down_amount.is_non_zero(). The deposit transaction before the runwithfirstdep transaction was used to manipulate the result of the get_lending_accumulator() function to make this value much larger and effectively make the scaled_down_amount to be 1. Post-attack analysis After the attack, the stolen funds were bridged from Starknet to the Ethereum blockchain. The attacker then attempted to launder the funds by depositing them into Railgun privacy pools but was prevented by the protocol's policies. The failed money laundering attempt emphasizes the importance of balancing privacy and transparency in the DeFi space. Lessons learned This incident highlights the importance of careful validation of input values in smart contracts, especially when dealing with complex and sensitive financial operations. By learning from incidents like this one, the DeFi community can build more resilient systems and better safeguard user funds.
MoonHacker Vault Hack Analysis
On December 23, 2024, the MoonHacker Vault suffered a devastating exploit, resulting in the loss of approximately $320,000 USDC. This blog delves into the technical details of the attack, analyzing the vulnerable contracts, attack methodology, and the lessons learned. Key Information Total Loss: $320,000 USDC Attacker Address: 0x36491840ebcf040413003df9fb65b6bc9a181f52 Attack Contracts: Contract 1 Contract 2 Vulnerable Contract: MoonHacker Vault Attack Transaction: 0xd12016b25d7aef681ade3dc3c9d1a1cc12f35b2c99953ff0e0ee23a59454c4fe Exploit The exploit targeted MoonHacker vault contracts interacting with the Moonwell DeFi protocol on Optimism. Improper input validation in the executeOperation function allowed the attacker to manipulate the system, resulting in unauthorized withdrawals. Vulnerability Details The root cause of the exploit was improper handling of inputs and lack of access control in the executeOperation function. This allowed the attacker to: Pass a malicious contract as the mToken address. Gain unauthorized token approvals and manipulate contract logic. Steps of the Attack Preparation: The attacker deployed two contracts to facilitate the exploit. Execution: By exploiting the lack of validation in the executeOperation function, the attacker manipulated the logic governing token approvals. Profit Extraction: The stolen funds were transferred to the attacker’s address. Mitigation and Best Practices To prevent similar exploits, the following measures are recommended: Input Validation: Validate the mToken address against a whitelist. Access Control: Implement role-based access control (RBAC) to restrict critical operations. Function Modifiers: Use specific modifiers or checks to ensure only trusted entities can interact with critical functions. Lessons Learned Comprehensive Audits: Ensure every contract is thoroughly reviewed for edge cases. Validation Checks: Implement robust validation mechanisms to prevent manipulation. Community Vigilance: Foster transparency and encourage community-driven security reviews. Conclusion The MoonHacker Vault exploit highlights the critical need for meticulous smart contract security practices. By learning from incidents like these, the DeFi community can build more resilient systems and safeguard user funds. Subscribe now For further insights, follow our updates on Twitter and subscribe to our newsletter.
